Hi TJ, thanks for mentioning the problem and the thorough write up.

We don't include any use of the IE classes in the default CSS because it is meant to work even if you don't use the helper classes. They also change the specificity of rules, meaning that if someone wanted to update the background color for all browsers they might be confused to find that their selector doesn't seem to affect IE.

There are also many text-like inputs that would need to be targeted...more than it is practical to include in a selector. Perhaps this can be sidestepped by using the generic input in the selector, but I haven't checked if this would have an undesired on submit inputs.

I'm also not sure about how possible or necessary it is to try and get all browsers to display disabled form controls in the same way by default. So I'm just going to leave this PR open for a while to have some time to ponder and come back to it later.

Thanks again.

Hi,

Regarding that PR, i'm wondering if it's not something more in the field of normalize.css. Adding

input[disabled], select[disabled], area[disabled], button[disabled] {
    background-color: #EBEBE4;
}

near https://github.com/necolas/normalize.css/blob/master/normalize.css#L429 will do the trick, at least in IE>6. Is specificity really a problem in this case?

I like this. Provides a better affordance for the user.

I know making a dependency on the IE classes is unprecedented, but an optional feature like this it seems reasonable.

@necolas In response to handling the other input types:

IE actually does a pretty good job making disabled buttons look disabled so nothing should need to be done for input[type="button"], input[type="reset"], and input[type="submit"]. However, it does look like input[type="file"] as well as input[type="password"] have the same issue since they are essentially rendering a text input. Conveniently if you apply a background-color to input[type="file"] IE will apply it to the file text input and not the file picker button. If you decide to include this request then input[type="password"] and input[type="file"] should be added. I believe that's all of the HTML4 input types, and since this is for IE <= 9 the HTML 5 input types are not relevant.

I agree that by including the IE classes there is a potential specificity issue, but I would think adding a background-color to form fields is a pretty uncommon thing to do. You had also mentioned the possibility of using the generic input selector, but even if it had no adverse effects it doesn't really help the specificity problem. The attribute selector is a drop in the bucket compared to the class selector, plenty of attribute selectors are already used in the boilerplate.

@Florian-R I don't think this makes sense in normalize because I don't believe it is a good idea to blindly apply this across all browsers. I'm specifically trying to fix this for IE since most all other browsers do a pretty decent job making disabled fields look non-interactable to the user (I have a bunch of images with how they all look here).

The idea is not necessarily to get a consistent look for disabled fields; it's to fix a usability issue in IE <= 9. All non-IE Windows browsers apply the grayish background-color so I thought it would make sense to make IE consistent. When there's no text in the input you really have no idea that the field can't be interacted with. I've seen people get frustrated / confused by this firsthand.

The HTML5 input types are relevant.

Just tested in IE8 and changing the type to anything other than text prevents the style being applied. I also see that just modifying the background color alters the border styles in IE8. Can't apply it to input in all/any browsers as this affects checkbox, radios, submit buttons, etc; not just their background but also affects their default borders in some browsers.

Applying these rules just to IE7/IE8 (via a method that I think is problematic) leaves IE9 looking different. You could make a case for only wanting to bring browsers in line on Windows, and leaving all the OSX browsers and the major browsers on mobile looking different, but why introduce relatively significant cross-browser differences that are different to those developers might expect when they are styling forms? And even then, we're still left with the same problems of specificity and depending on HTML that might not be there.

I'm starting to think this is something that is a level outside of the boilerplate's starting CSS.

Perhaps it could be added to the Better Web Development CSS section.

That way, it's not included in the base code, but users are still made aware of the issue, and are given the option of including it themselves.

@necolas I agree with your arguments. I might feel differently if the boilerplate still applied an ie9 class, but it doesn't, so I agree that this belongs at a level outside of the boilerplate. Do you think this is worthy of a mention in the CSS section of Better web development Wiki per @AndrewBrinker's comment? If so I can add it.

@tjvantoll Why not. You've got a good and detailed post about your research. Feel free to add it to the wiki (and also a link to this issue for the additional discussion we've had) and then please close this issue when you're finished. Thanks!

Done. Thanks for your time and feedback.